home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 6⁄1⁄90 / 1361-Re RE[3] Object Styl-May90 < prev    next >
Encoding:
Text File  |  1990-06-01  |  2.6 KB  |  60 lines  |  [TEXT/GEOL]
  1. Item    1208133                         29-May-90        10:50PDT
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     MADA2                           MacApp Dev Assoc, Curtis Faith,IVC
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: RE[3] Object Style
  10.  
  11. Curtis:
  12.  
  13. If a Get/Set method is monomorphic then the extra performance overhead (vs.
  14. direct field access) is just a procedure call with one parameter.  Also, you
  15. automatically eliminate 1 jump table entry, and possibly 2 if all calls to the
  16. method are from the segment containing the method.  (This is only in non-debug
  17. mode.)
  18.  
  19. I agree with you that Get/Set methods are rarely the performance bottleneck.
  20. This is why it is important to do measurements and find out where the
  21. bottleneck actually is.  (I think your performance conclusions aren't valid,
  22. however, because people know that performance of Get/Set methods isn't a
  23. problem on a 50MHz 030.  A Mac Plus is probably 1/10 as fast, so on that
  24. machine only 200 Gets adds .01 seconds.)
  25.  
  26. C++ inline functions have no space or time overhead compared to a direct field
  27. access.  The code generated by GetSomeObject.DoSomeMethod and
  28. fSomeObject.DoSomeMethod should be identical if GetSomeObject is inline.
  29.  
  30. It is important to realize that using inline functions in this case doesn't
  31. completely isolate the client from the implementation of the class.  The code
  32. to access the field is compiled into the client, which means if the
  33. representation of the class changes, the client must be recompiled.
  34.  
  35. Also, if you declare a virtual method as inline, the compiler will often not
  36. compile the method inline.  So if you expect people to override the Get/Set
  37. method, then it probably won't help to make it inline.  (That's OK because you
  38. are going to pay the method dispatching overhead anyway.)
  39.  
  40. One drawback of an inline function is that their code is duplicated each time
  41. they are called.  This isn't a problem in pure Get/Set function.  Another
  42. drawback is that Object Pascal doesn't have inline, if you need to make the
  43. class usable from both languages.
  44.  
  45. I have wrestled with the question of whether methods of a class should directly
  46. access its fields.  In most cases, I do directly access fields, especially in
  47. C++, where I can make all the fields private.  I'm not sure that having private
  48. Get/Set methods buys you much.  You don't get any additional safety or
  49. cleanliness, and the function call syntax hides the fact that you are accessing
  50. a field.
  51.  
  52. I think Neil is right about having a naming convention that distinguishes pure
  53. Get/Set methods from methods that are more complicated, but also access an
  54. object's attribute.
  55.  
  56. Larry Rosenstein
  57.  
  58.  
  59.  
  60.